A corporation having several business entities may want to administratively separate individual user and computer accounts associated with the separate businesses for such reasons as security, administrative control, budget separation, geographic affinity, political separation, and the like. Each business entity can be implemented as a domain which is a networked group of interconnected computing entities such as servers and clients. Each domain can be structured as a secured unit typically having a computer implemented as a domain controller to locally administrate network access and domain functions. A corporation is only one example of any company, organization, or enterprise having separable divisions and sub-divisions that are setup as independent and secure domains.
To manage closely related business entities, such as within a corporation, each respective domain can be interconnected within a “forest”. When domains are grouped together and implemented as a network system in a forest, the forest boundary becomes the trust (e.g., security) boundary and the unit of administrative isolation for the group of domains. Such a configuration can be implemented with Active Directory™ which is an enterprise-wide directory service in Windows® 2000. Windows® 2000 is an operating system available from Microsoft Corporation of Redmond, Wash.
For the reasons that an enterprise having separable divisions may implement each division as a separate domain, the enterprise may also want to implement multiple forests. In particular, administrative autonomy and asset isolation are reasons to implement multiple forests. Administrative autonomy may be desired if separate divisions do not trust another's administrators for political or security reasons, or if the divisions cannot agree on common change control or configuration policies. Asset isolation may be desired if separate governmental agencies and/or business divisions are conglomerated via mergers and acquisitions, yet wish to maintain separate and independent network system infrastructures for security or budgetary reasons.
In a distributed network-wide directory service, enterprise-wide address lists, calendars, schedules, distribution lists, and the like are not supported across forest boundaries without manual directory synchronization of user accounts. When administrative autonomy or asset isolation is required, directory synchronization may not be possible due to schema differences, or may not be allowed because of the personnel information that would be disclosed.
The usability and manageability afforded by the cohesiveness of multiple domains in a single forest is given up when implementing multiple forests to attain secure isolation for enterprise divisions. In many cases, however, resources need to be shared between the different forests of a distributed enterprise. An email system serving all divisions of a particular enterprise is an example of an application that requires multiple forest access authorization. Additionally, users that travel between geographically separated divisions within an enterprise need to be able to logon with their credentials at a remote forest domain and access resources throughout an enterprise.
In a single forest, a trust link between two domains enables security principals from one domain to be authenticated in another domain. When a first domain is configured to trust a second domain, the first domain is “trusting” and the second domain is “trusted”. The first domain trusts the second domain to authenticate users of the second domain when the users attempt to gain access to protected resources in the trusting, or first, domain. The trusted domain makes its accounts available to be used in the trusting domain. The trusting domain allows the trusted domain to return a list of account and group membership information to identify users authenticated by the trusted domain.
Multiple forests do not inherently trust each other. With conventional networked systems, it is difficult to manage a trust link across multiple forests because there is no provision to establish trust across different forest boundaries. Currently, the only type of trust supported between domains in separate forests is “external trust”. This is direct, non-transitive trust between two domains in separate forests. An administrator has to manually establish a separate trust link between every pair of domains in two forests if a user from any domain in the first forest is going to logon to a computer from any domain in the second forest. However, establishing a mesh of direct trust links between all of the domains of multiple forests is an unmanageable and onerous task for system administrators.
Except for manually established direct domain-to-domain trust links, it is not possible to perform such tasks as accessing shared resources across multiple forest boundaries. Without being able to establish a trust link between multiple forests, it is not known where to route authentication and/or authorization requests that can be serviced by domains in other forests.
Authentication is the process of verifying the identity of a security principal when access to a secured resource is requested. The verification process can be applied to users, computers, and/or services executing in the security context of a user or computer. Typically, user authentication is implemented in either of two ways. One way is to associate a username with a password and require both the username and password at the time of an initial request to access a network system. A second way is to use secure access tokens granted by an operating system to authentic users.
Once authentication has been accomplished, authorization is the process of determining whether a security principal is allowed to perform a requested action. Authorization uses information about the security principal to determine which resources the security principal can access. A common technique consists of comparing security identifiers that represent the security principal and associated group memberships with an access control list that specifies the identities that may access a given resource, and what type of access is allowed.
Kerberos is one example of a secure method for mutually authenticating both users and services in a computer network. Kerberos allows a user to obtain an encrypted ticket-granting-ticket that can then be used to request a service ticket for a particular service on a network server. With a service ticket, the user's password does not have to pass through the network. A Kerberos ticket provides a secure way to transport an encryption key that is shared between a user and a server for authentication across a potentially non-trusting network.
To get a ticket-granting-ticket, Kerberos authenticates a user from an authentication server. The authentication server creates the encryption key to be shared between the user and a ticket granting service. Two copies of this encryption key are returned to the user, one of which is encrypted in the user's master key (a key derived from the user's password) and the other which is placed in the ticket-granting-ticket to be encrypted in the master key of the ticket granting service. The ticket-granting-ticket is then sent to the ticket granting service along with a request for a service ticket for a particular server or service on the network. The ticket granting service returns the service ticket that can be sent to a network server for the requested service or resource access. When the user attempts to logon to the server, the service ticket is provided with an authenticator (a Kerberos data structure encrypted under the same session key that was placed in the service ticket). When the server receives a service ticket and an authenticator, the server has enough information to authenticate the user. A subsequent network exchange can be performed to enable the user to authenticate the server.
A ticket-granting-ticket is time-stamped to allow a user to make additional requests using the same ticket within a certain time period without having to be reauthenticated. Issuing a valid ticket for a limited time period makes it less likely that a second user will later be able to acquire and use the ticket inappropriately.
FIG. 1 shows a conventional network architecture 100 representing an enterprise having two separable divisions implemented as forests A and B. Each forest A and B is an administratively isolated network system 102 and 104, respectively. Network system 102 has two domains 106(1) and 106(2) each having a computer implemented as a domain controller 108(1) and 108(2), respectively. The two domains 106 form a domain tree with a bi-directional trust link 110 that is automatically established when an administrator creates a second domain, such as domain 106(2). A domain tree is established with multiple domains and forms a contiguous namespace.
The domain controllers 108 in forest A implement a network-wide partitioned directory, such as Active Directory™ which is an enterprise-wide directory service in Windows® 2000. Windows® 2000 is an operating system available from Microsoft Corporation of Redmond, Wash. The domain controllers 108 can also implement other directory services, such as NDS eDirectory available from Novell, an iplanet directory service available from Sun Microsystems Inc., or the like. Each domain controller 108 in a separate domain 106 of the network system 102 maintains a copy of a partition of the directory which typically contains those objects that are pertinent only to a particular domain. Pertinent objects include those that facilitate the administration of security principals' authentication, authorization, and network access at a particular domain controller.
Domain 106(1) includes a global catalog server 112 that maintains network-wide information for network system 102 and is communicatively linked to the domain controllers 108 via a network communications system (not shown). In a network configuration, a global catalog server can be implemented to maintain a directory of all the user and group memberships within the network for each user and group account authorized to access the network. Global catalog server 112 provides a central information source that can be accessed by domain controllers 108 to locate and access network-wide resources upon user request. Network system 102 has a workstation 114 connected to domain controller 108(1) to facilitate a user request to access network system 102.
Similar to network system 102, network system 104 is an administratively isolated forest. Network system 104 has two domains 116(1) and 116(2) each having a computer implemented as a domain controller 118(1) and 118(2), respectively. The two domains 116 form a domain tree with a bi-directional trust link 120. The trust link 120 between the two domains 116 enables a user with an account in one domain to have access to resources in another domain within the boundary of forest B. When trust links are established between domains, user and group objects from the directory can be given access rights and permissions in domains other than the domain where these objects are located.
Domain 116(1) includes a global catalog server 122 that maintains network-wide information for network system 104 and is communicatively linked to the domain controllers 118 via a network communications system (not shown). Network system 104 also has a resource server 124 that maintains network-wide accessible resources. The resources are only available within forest B, however, because of the administrative isolation from forest A.
It is possible for administrators to manually create an explicit trust link between domains in separate forests. However, even when creating a sufficient trust link, Kerberos authentication between forests frequently fails. The primary cause is that either the username, or the service name, cannot be resolved by a domain controller or global catalog server in the forest where the logon request originates. This causes Kerberos authentication to fail for both interactive and network logon requests when the user and service accounts are managed in different forests.
For example, if a user at workstation 114 in forest A requests access to the resource server 124 in forest B, the Kerberos service ticket request will fail. When workstation 114 at forest A sends a Kerberos service ticket request for resource server 124 to domain controller 108(1), the domain controller will not find the service name in its local database. It then queries the global catalog server 112 in forest A for the resource server 124. The global catalog server 112, however, does not recognize the requested service name either. Thus, Kerberos authentication fails.
If both the workstation 114 and resource server 124 support a common operating system authentication protocol, the workstation and resource server can negotiate authentication via an external trust relationship so that a logon request can succeed. However, conventional operating system authentication protocols do not provide equivalent Kerberos functionality, such as mutual authentication, and/or delegation. Therefore, a user can not access a resource in a forest that is beyond the security boundary of the user's home forest if the connection requires mutual authentication or delegation.